COMMENT ⊗   VALID 00004 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	COMMENTS ON BUYING TERMINALS FOR UCLA
C00005 00003	Laying wire from CCBS to NPI
C00009 00004	TTY - CCBS interaction
C00015 ENDMK
C⊗;
COMMENTS ON BUYING TERMINALS FOR UCLA

REASONABLE CHARACTERISTICS:

24 x 80 characters on a screen
  sail terminals have 40 x 82 chars
9600 baud, at least for screen refresh
  1 baud = 1 bit/sec.   10 baud approx = 1 char/sec, since 1 char = 8 bits
128 character ASCII (96 printable) 7 bit ascii (plus 1 parity bit)
x-y positioning of cursor
cursor interrogate (only needed if the terminal does something on its own)

  cost for the above:  $1800 per (keyboard + screen)

We need to know the type of interface at the computer.
We need dedicated lines (4-wire lines) from computer to terminal area.
  When they lay them, get them to lay half a dozen at once, because each
   quad line can handle only one terminal, unless you put a multiplexer at each end.

Other things to think about:

A meta key is useful, but not necessary if we can find enough unused control chars.
  We need enough control chars for the line editor.
  Display editor commands (commands that delete, attach, or insert lines)
    can always be done with 2 sequential commands.

The line editor needs special system modifications to generate the interrupt
  which will process the command.  The first step is to get a line editor
  into a display editor.  Then convince the management that it should be
  done at the tty-handler level.

Smart terminals are not yet stable enough to buy right now.  Look for better ones
  in 1-2 years.

We could get 3 dumb terminals, and one small mini to service them.  The appropriate
  mini might be an LSI 11 for about $2-3K.  Ted says it is slow.


CURRENT PROPOSAL:

 get 3 dumb terminals at $1800 per terminal

 run 6-8 lines (or let them figure out how to wire us between NPI and CCBS)

 do all the system modification for line editors, display editors, and mapping


Laying wire from CCBS to NPI

  We basically need to run 1 pair of wires for each keyboard and 1 pair
of wires for each screen.  The keyboard wires only have to be run at 
300 baud (30 cps) and therefore can be simple twisted pair lines.
The screen wires want to be run at 9600 baud, and in order to run 
that fast they need shielding, and drivers and listeners at each end.
(This assumes the distance is greater than 100 feet and less than 1 mile.)

  Assuming we have 3 terminals, Ted says we should run enough lines for
6 terminals, because we need 1 or 2 extra for backup (what if one line
breaks or fails somewhere), and also allow for more terminals to be
added, either by us, or anyone else in NPI.   For now lets assume that
the distance is 2500 feet (although hopefully shorter).

  So, we could either get:
				part #	price for 500 ft	cost 

2500 feet of belden beldfoil	87-78	@ $189			$ 945
 (6 pr shielded pairs)

2500 feet of stranded 		87-47	@ $ 85			$ 425
 (6 pr twisted pairs)

							       $ 1350

or put them all in one big cable (saves laying costs):

2500 feet of belden beldfoil	97-68	@ $352		       $ 1760
 (12 pr shielded pairs)


  In addition, we need (only for the 9600 baud screen lines) drivers 
to boost the signal at the computer, and listeners to amplify the signal
at the screen end.  These could be done by a (as Ted puts it) poor
EE grad student looking for money and something to do for about $100
for all of them.

  One potential saving is to find some phone lines between CCBS and NPI
which we could use.  These would replace the 300 baud lines, but not the
9600 baud lines, since phone lines are no good at high speeds without
modems.  


  The alternate route is to use phone lines entirely.  In this case, we
would need modems.  Modems to drive data at 9600 baud cost $1000 apiece,
and one needs two of them for each line (one at each end).  Or, we
could reduce the speed to 300 baud (30 cps) and use our screens at
teletype speeds.  This would eliminate display editors and mapping
between jobs.


TTY - CCBS interaction

  Basically, we want 2-3 terminals, depending upon how many people 
will be physically at the terminals.  We also want a mapping feature,
a display editor, and a line editor.   We will run into several
problems:
  
  The line editor will take: 
1) several unused (or unused by most things) ascii character codes 
out of the standard 128 (a minimum of 4, but 10 would be better);  
2) permission to modify the system so that our special codes will 
interrupt the system;
  This much would allow us a line editor for any program that we wrote
it into, but not in general at the monitor level.  

  A display editor will take:
1) a line editor
2) a terminal that can be refreshed quickly, and interrogated
3) a random-access file storage capability (it should already be there).

  A mapping feature is the hardest.  It is easy to map keyboards by 
adding a small table in the operating system to send the characters
from the tty interface to the proper buffer.  The problem is displaying
it, because the system totally forgets what is on the screen as soon
as it has written it out (except for a display editor, which remembers
in the user program).  So if we map, we either have to forget what has
gone before (no good), or have the system remember what is on each
screen (JAM says this system mod would take 2-3 man-months), or
the special kludge that I have thought up.

  The special kludge takes advantage of ptyjobs.  Basically, we have
one job (call this the "control job") resident in core that services 
the 3 terminals as i/o devices.  The control job then runs all of
the jobs that the terminals desire, saving all of the output 
so that any screen can be refreshed with the output of any running
job (map).  Or instead of a ptyjob, the control job can run a 
network job, and serve as the network server.  As long as the control
job has a line editor and knows what one screenful of data is,
it might also be the simple display editor, although with a capacity
for only storing one screenful in core at a time.

  Problems with this are all of time consumption.  The extra layer
for local jobs is substantial.  For network jobs, the overhead is
almost nothing, since we need to have a telnet job anyway.
Note that perhaps we could have a line editor within this control
job, and thus extend the line editor to the monitor level.

  One way out of this time problem is to be in core all the time,
and run for very short periods of time at each interrupt.  If we could
keep the control program to 5-6k, then it reasonable replaces the
net jobs we would have.  

  The sequence for writing all of these programs:
1) a tty server that handles up to 3 terminals, saves the screenful
of data, and runs any number of ptyjobs (including sos and telnet
temporarily).
2) a line editor on the front of the tty server.
3) a display editor
4) a telnet server in the tty server

  The two problems are:
a) time involved with writing all these programs.  But if it takes 
less that 2 man-months I think it would be worth it.
b) the bureauracracy at ccbs.  They would have to approve of us:
having our tty server resident in core, being able to map keyboards
and screens, and passing tty interrupts on to our server program.

  Note: it may be that the PDP11 does all of the tty serving, in
which case we can write the line editor into the PDP11.  This would
make our control program much simpler, and perhaps it wouldnt have
to be resident in core.